Hadoop v1

1.0

Hadoop 1.0即第一代Hadoop，由分布式存储系统HDFS和分布式计算框架MapReduce组成，其中，HDFS由一个NameNode和多个DataNode组成，MapReduce由一个JobTracker和多个TaskTracker组成，对应Hadoop版本为Apache Hadoop 0.20.x、1.x、0.21.X、0.22.x和CDH3。

组件

Apache Hadoop V.1.x has the following two major Components

1. HDFS (HDFS V1)
2. MapReduce (MR V1)

In Hadoop V.1.x, these two are also know as Two Pillars of Hadoop.

MapReduce体系结构

来源1

所谓的经典版本的MapReduce框架，也是Hadoop第一版成熟的商用框架，简单易用是它的特点，来看一幅图架构图：

上面的这幅图我们暂且可以称谓Hadoop的V1.0版本，思路很清晰，各个Client提交Job给一个统一的Job Tracker，然后Job Tracker将Job拆分成N个Task,然后进行分发到各个节点（Node）进行并行协同运行，然后再讲各自的运行结果反馈至Job Tracker,进而输出结果。

下面我们再详细的分析下Job Track在MapReduce中的详细职责，解决扩张性的问题无非就是责任解耦，我们来看一下：

1、管理集群中的计算资源，涉及到维护活动节点列表，可用和占用的Map和Reduce Slots列表。以及依据所选的调度策略可用的Slots分配给合适的作用和任务

2、协调集群中运行的任务，这涉及到指导Task Tracker启动Map和Reduce任务，监视任务的运行状态，重新启动执行失败任务，推测性能运行缓慢的任务，计算作业计数器值的总和，等等。

JobTracker的职责分为两大部分：集群资源管理和任务协调。

来源2

在Hadoop里面的MapReduce的是有存在两个不同的时期.刚开始的Hadoop中的MapReduce实现是做到很多的事情，而该框架的核心Job Tracker(作业跟踪者)则是既当爹又当妈的意思.看下图:

​

原 MapReduce 程序的流程及设计思路：
1.首先用户程序 (JobClient) 提交了一个 job，job 的信息会发送到 Job Tracker 中，Job Tracker 是 Map-reduce 框架的中心，他需要与集群中的机器定时通信 (heartbeat), 需要管理哪些程序应该跑在哪些机器上，需要管理所有 job 失败、重启等操作。
2.TaskTracker 是 Map-reduce 集群中每台机器都有的一个部分，他做的事情主要是监视自己所在机器的资源情况。
3.TaskTracker 同时监视当前机器的 tasks 运行状况。TaskTracker 需要把这些信息通过 heartbeat发送给JobTracker，JobTracker 会搜集这些信息以给新提交的 job 分配运行在哪些机器上。

来源3

1. Job Submission Each job is submitted from a user node to the JobTracker node that might be situated in a different node within the cluster through the following procedure:

   • A user node asks for a new job ID from the JobTracker and computes input file splits.

   • The user node copies some resources, such as the job’s JAR file, configuration file, and computed input splits, to the JobTracker’s file system.

   • The user node submits the job to the JobTracker by calling the submitJob() function.

2. Task assignment The JobTracker creates one map task for each computed input split by the user node and assigns the map tasks to the execution slots of the TaskTrackers. The JobTracker considers the localization of the data when assigning the map tasks to the TaskTrackers. The JobTrackeralso creates reduce tasks and assigns them to the TaskTrackers. The number of reduce tasks is predetermined by the user, and there is no locality consideration in assigning them.

3. Task execution The control flow to execute a task (either map or reduce) starts inside the TaskTracker by copying the job JAR file to its file system. Instructions inside the job JAR file are executed after launching a Java Virtual Machine (JVM) to run its map or reduce task.

4. Task running check A task running check is performed by receiving periodic heartbeat messages to the JobTracker from the TaskTrackers. Each heartbeat notifies the JobTracker that the sending TaskTracker is alive, and whether the sending TaskTracker is ready to run a new task.

容错

1. 任务出错

任务出错是比较常见的，引起错误的原因通常有低质量的代码、数据损坏、节点暂时性故障、一个任务出现下列三种情况的任意一种时被认为出错。
（1）抛出一个没有铺货的异常
（2）以一个非零值退出程序
（3）在一定的事件内没有向Tasktracker报告进度。
当TaskTracker检测到一个错误，TaskTracker将在下一次心跳里向JobTracker报告该错误，JobTracker收到报告的错误后，将会判断是否需要进行重试，如果是，则重新调度该任务。默认的尝试次数为4次，可以通过mapred-site.xml的配置项mapreduce.map.maxattempts配置。该任务可能在集群的任意一个节点重试，这取决于集群资源的利用情况。如果同一个作业的多个任务在同一个TaskTracker节点反复失败，那么JobTracker会将该TaskTracker放到作业级别的黑名单，从而避免将该作业的其他任务分配到该TaskTracker上。如果多个作业的多个任务在同一个TaskTracker节点反复失败，那么JobTracker会将该TaskTracker放到一个全局的黑名单24小时，从而避免所有作业的任务呗分配到TaskTracker上。
当一个任务经过最大尝试数的尝试运行后仍然失败，那么整个作业将被标记为失败。如果我们不希望这样（因为可能作业的溢写结果还是可用的），那么可以设置允许在不处罚整个作业失败的任务失败的最大百分比。

2. TaskTracker出错

   当TaskTracker进程崩溃或者TaskTracker进程所在节点故障时，JobTracker将接收不到TaskTracker发来的心跳，那么JobTracker将会认为该TaskTracker失效并且在该TaskTracker运行过的任务都会被认为失败，这些将会被重新调度到别的TaskTracker执行，而对于用户来说，在执行MapReduce任务时，只会感觉到该作业在执行的一段时间里变慢了。

3. JobTracker出错

   在Hadoop中，JobTracker出错是非常严重的额情况，因为在Hadoop中JobTracker存在单节点故障的可能性，所以如果如果JobTracker一旦出错，那么正在运行的所有作业的内部状态信息将会丢失，即使JobTracker马上恢复了，作业的所有任务都会被认为是失败的，即所有作业都需要重新执行。

4. HDFS出错

   对于依赖底层存储HDFS的作业，一旦HDFS出错，那么对于整个作业来说，还是会执行失败，当DataNode出错时，MapReduce会从其他DataNode上读取所需数据，除非包含任务所需的数据块的节点都出错，否则都是可以恢复的。如果NameNode出错，任务将在下一次访问NameNode时报错，但是MapReduce计算框架还是会尝试执行4次（默认的最大尝试执行次数为4），在这期间，如果NameNode依然处于故障状态，那么作业会最终执行失败。

问题

既然出现Hadoop2改进它,那它就有一些问题咯。主要的问题如下:

1. JobTracker 是 Map-reduce 的集中处理点，存在单点故障。

2. JobTracker 完成了太多的任务，造成了过多的资源消耗，当 map-reduce job 非常多的时候，会造成很大的内存开销，潜在来说，也增加了 JobTracker fail 的风险，这也是业界普遍总结出老 Hadoop 的 Map-Reduce 只能支持 4000 节点主机的上限。

3. 在 TaskTracker 端，以 map/reduce task 的数目作为资源的表示过于简单，没有考虑到 cpu/ 内存的占用情况，如果两个大内存消耗的 task 被调度到了一块，很容易出现 OOM。

4. 在 TaskTracker 端，把资源强制划分为 map task slot 和 reduce task slot, 如果当系统中只有 map task 或者只有 reduce task 的时候，会造成资源的浪费，也就是前面提过的集群资源利用的问题。

   源代码层面分析的时候，会发现代码非常的难读，常常因为一个 class 做了太多的事情，代码量达 3000 多行造成 class 的任务不清晰，增加 bug 修复和版本维护的难度。

5. 从操作的角度来看，现在的 Hadoop MapReduce 框架在有任何重要的或者不重要的变化 ( 例如 bug 修复，性能提升和特性化 ) 时，都会强制进行系统级别的升级更新。更糟的是，它不管用户的喜好，强制让分布式集群系统的每一个用户端同时更新。这些更新会让用户为了验证他们之前的应用程序是不是适用新的 Hadoop 版本而浪费大量时间。

Hadoop v2

2.0

Hadoop 2.0即第二代Hadoop，为克服Hadoop 1.0中HDFS和MapReduce存在的各种问题而提出的。针对Hadoop 1.0中的单NameNode制约HDFS的扩展性问题，提出了HDFS Federation，它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展，同时它彻底解决了NameNode 单点故障问题；针对Hadoop 1.0中的MapReduce在扩展性和多框架支持等方面的不足，它将JobTracker中的资源管理和作业控制功能分开，分别由组件ResourceManager和ApplicationMaster实现，其中，ResourceManager负责所有应用程序的资源分配，而ApplicationMaster仅负责管理一个应用程序，进而诞生了全新的通用资源管理框架YARN。基于YARN，用户可以运行各种类型的应用程序（不再像1.0那样仅局限于MapReduce一类应用），从离线计算的MapReduce到在线计算（流式处理）的Storm等。Hadoop 2.0对应Hadoop版本为Apache Hadoop 0.23.x、2.x和CDH4。

组件

Apache Hadoop V.2.x has the following three major Components

1. HDFS V.2
2. YARN (MR V2)
3. MapReduce (MR V1)

In Hadoop V.2.x, these two are also know as Three Pillars of Hadoop.

YARN

首先的不要被YARN给迷惑住了,它只是负责资源调度管理,而MapReduce才是负责运算的家伙,所以**YARN != MapReduce2.**这是大师说的:

YARN并不是下一代MapReduce（MRv2），下一代MapReduce与第一代MapReduce（MRv1）在编程接口、数据处理引擎（MapTask和ReduceTask）是完全一样的， 可认为MRv2重用了MRv1的这些模块，不同的是资源管理和作业管理系统，MRv1中资源管理和作业管理均是由JobTracker实现的，集两个功能于一身，而在MRv2中，将这两部分分开了， 其中，作业管理由ApplicationMaster实现，而资源管理由新增系统YARN完成，由于YARN具有通用性，因此YARN也可以作为其他计算框架的资源管理系统，不仅限于MapReduce，也是其他计算框架(Spark).

MapReduce (YARN).它的架构图如下:

​

在Hadoop2中将JobTracker两个主要的功能分离成单独的组件，这两个功能是资源管理和任务调度/监控。新的资源管理器全局管理所有应用程序计算资源的分配，每一个应用的 ApplicationMaster 负责相应的调度和协调。一个应用程序无非是一个单独的传统的 MapReduce 任务或者是一个 DAG( 有向无环图 ) 任务。ResourceManager 和每一台机器的节点管理服务器能够管理用户在那台机器上的进程并能对计算进行组织

1. 事实上，每一个应用的ApplicationMaster是一个详细的框架库，它结合从ResourceManager获得的资源和 NodeManagr 协同工作来运行和监控任务。
2. 在上图中ResourceManager支持分层级的应用队列，这些队列享有集群一定比例的资源。从某种意义上讲它就是一个纯粹的调度器，它在执行过程中不对应用进行监控和状态跟踪。同样，它也不能重启因应用失败或者硬件错误而运行失败的任务。
   ResourceManager 是基于应用程序对资源的需求进行调度的 ; 每一个应用程序需要不同类型的资源因此就需要不同的容器。资源包括：内存，CPU，磁盘，网络等等。可以看出，这同现 Mapreduce 固定类型的资源使用模型有显著区别，它给集群的使用带来负面的影响。资源管理器提供一个调度策略的插件，它负责将集群资源分配给多个队列和应用程序。调度插件可以基于现有的能力调度和公平调度模型。
3. 在上图中 NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源使用情况 (CPU，内存，硬盘，网络 ) 并且向调度器汇报。
4. 在上图中,每一个应用的 ApplicationMaster的职责有：向调度器索要适当的资源容器，运行任务，跟踪应用程序的状态和监控它们的进程，处理任务的失败原因。

​

再次总结,在Hadoop2集群里,一个客户端提交任务的一整套的流程图:

​

1. 客户端的mapreduce程序通过hadoop shell提交到hadoop的集群中.
2. 程序会通过RPC通信将打成jar包的程序的有关信息传递给Hadoop集群中RM(ResourceManager),可称为领取JOBID的过程
3. RM根据提交上来的信息给任务分配一个唯一的ID,同时会将run.jar的在HDFS上的存储路径发送给客户端.
4. 客户端得到那个存储路径之后,会相应的拼接出最终的存放路径目录,然后将run.jar分多份存储在HDFS目录中,默认情况下备份数量为10份.可配置.
5. 客户端提交一些配置信息,例如:最终存储路径，JOB ID等.
6. RM会将这些配置信息放入一个队列当中,所谓的调度器.至于调度的算法,则不必深究.
7. NM(NodeManager)和RM是通过心跳机制保持着通信的,NM会定期的向RM去领取任务.
8. RM会在任意的一台或多台的NM中，启动任务监控的进程Application Master.用来监控其他NM中YARN CHild的执行的情况
9. NM在领取到任务之后,得到信息，会去HDFS的下载run.jar.然后在本地的机器上启动YARN Child进程来执行map或者reduce函数.map函数的处理之后的中间结果数据会放在本地文件系统中的.
10. 在结束程序之后,将结果数据写会HDFS中.整个流程大概就是这样子的.

详见：

• Differences between Hadoop 1.x and Hadoop 2.x, Hadoop 1.x Limitations and Hadoop 2.x YARN Benefits

• Hadoop V1到Hadoop V2的主要变化

• Hadoop中MapReduce框架入门

• Hadoop 之 MapReduce 框架演变详解

1
2